For some years, different types of radio networks for wireless communication have been developed to provide radio access for various wireless terminals in different areas. The radio networks are constantly improved to provide better coverage and capacity to meet the demands from subscribers using increasingly advanced services and terminals, e.g. smartphones and tablets, which may require considerable amounts of bandwidth and resources for data transport in the networks. A limiting factor for capacity of a radio network is the amount of available radio resources, e.g. in terms of time, frequency bandwidth and transmit power, and the capacity of a radio network is improved by more efficient usage of such radio resources.
In the field of mobile or wireless communication, the term “wireless device” is often used and will be used in this disclosure to represent any communication entity capable of radio communication with a radio network by sending and receiving radio signals, such as e.g. mobile telephones, tablets and laptop computers. Another common term in this field is “User Equipment, UE”. A wireless device in this context could also be a machine-to-machine type of device operating automatically such as a sensor, counter or measuring entity which is configured to send reports over the radio network e.g. at certain intervals or upon certain events. Further, the term “network node”, is used here to represent any node of a radio network that is arranged to communicate radio signals with wireless devices. The network node in this context is sometimes also referred to as a base station, radio node, e-NodeB, eNB, NB, base transceiver station, access point, etc.
It is becoming increasingly common to employ so-called “Machine-to-Machine”, M2M, devices which are typically installed at certain locations to operate automatically by sending and receiving data according to a predefined behavior. For example, equipment and procedures have been developed for monitoring various locations, areas and functions that need to be supervised, where M2M devices can be installed at different locations within a monitored area to perform some predefined operational task such as measuring, counting, detecting or sensing, and typically reporting the result to a central server or the like. These devices may be configured to measure or observe some metric or parameter of interest, such as temperature, pressure, voltage, battery level, light, motion, sound, presence of objects, presence of smoke, to mention a few illustrative examples.
Some common examples of M2M device installations include public and private buildings, infrastructures, vehicles, industrial premises, machines, communication networks, and so forth. The devices may use radio access over a radio network to report sensor data comprising information about their measurements and observations to the server, e.g. at regular intervals or triggered by occurrence of an event, e.g. detection of motion, sound, vibration, light, smoke, temperature rise, and so forth. The server may further send various commands and instructions back to the devices to control their operation.
An example of an arrangement for monitoring a particular area is schematically illustrated in FIG. 1 where a plurality of M2M devices “D” are distributed at different locations within a schematically shown monitored area 100, the devices D being configured to perform various measurements and observations at their respective locations and to send reports over a radio network 102 to a central monitoring server 104, as indicated by arrows “R”. The server 104 may also send various commands to control operation of the devices D, as indicated by opposite arrows “C”.
As mentioned above, it is of interest for network operators to improve capacity in their networks by utilizing the available radio resources as efficiently as possible. Another area of interest is to ensure reliability when data is transmitted to or from the wireless devices, e.g. M2M devices, so that no errors occur in the information communicated, if this is deemed important. This can be achieved by adding extra control bits in the transmission which can be used for error correction and/or for checking that there is no error in the received data, e.g. after make an attempt at error correction. A common method for error detection is the well-known Cyclic Redundancy Check, CRC, where basically a sum of the transmitted data may be checked.
If a data receiving node determines, e.g. by using CRC or other error detecting method, that data has not been received correctly from a data sending node, it may send an error indicating message back to the data sending node which then may send the same data once again to the data receiving node, referred to as retransmission. A commonly used process for enabling retransmissions of erroneously received data is the well-known Hybrid Automatic Repeat Request, HARQ, process. Retransmissions may be employed if it is important that the data is correct when received, such as in M2M reporting of measurements and observations. On the other hand, a certain amount of errors can normally be tolerated in speech or video data and retransmissions may in that case not be motivated.
The HARQ process or similar generally requires a node receiving data from another node to indicate whether a transmitted chunk of data has been properly received and decoded or not, by sending a feedback message to the data sending node. In this context, the term “forward link” refers to the link used for conveying data and the term “reverse link” refers to the link used for conveying feedback messages.
FIG. 2 illustrates a simple example of how this is basically done. In a first action 2:1, a data sending node denoted data sender 200 transmits a piece of data on a forward link to a data receiving node denoted data receiver 202. The data sender 200 may be a network node and the data receiver 202 may be a wireless device, or vice versa, and this procedure may be applied in either direction. Having received the data, the data receiver 202 checks if the data has any errors, e.g. by using the above-mentioned CRC for error detection, in another action 2:2. The data receiver 202 then returns a feedback message accordingly on a reverse link to data sender 200, in a next action 2:3.
The feedback message is either an acknowledgement, ACK, which confirms correct reception of the data, or a non-acknowledgement, NACK, which indicates an error in the received data or no reception at all, depending on the outcome of action 2.2 When receiving a NACK, the data sender 200 is required to retransmit the same chunk of data, as indicated by an optional action 2:4, to enable another attempt of reception and decoding at the data receiver 202. The HARQ process is widely known as such in this field and it is not necessary to describe in any further detail to understand the following disclosure. It should be understood that a certain amount of radio resources must be allocated for enabling the above-described communication of feedback messages. Even though the indication of ACK or NACK as such requires only one bit, 1 or 0, for each feedback message, a considerable amount of overhead is needed apart from that bit to enable this process.
However, it is a problem that considerable amounts of radio resources may be spent to no avail regardless of whether a feedback procedure such as the above-described HARQ process is employed or not. For example, when a feedback procedure is employed, a certain amount of extra radio resources must be allocated on the reverse link which may be a waste of radio resources in case the radio conditions are good and there are virtually no errors in the data communication, still requiring the data receiver to keep sending the feedback messages.
On the other hand, if no feedback procedure is employed, thus not requiring any extra radio resources, it is necessary to ensure that no data errors occur for applications where the data receiving node is very error-sensitive and requires correct data reception. This may be achieved by using a relatively large amount of radio resources for the data transmission on the forward link, e.g. by employing added error correction bits and/or high transmit power, to ensure correct data reception even when the radio conditions are bad. In order to ensure this, the radio resources for data must be dimensioned for a “worst-case scenario”, which may require something like 10 times more radio resources than what is normally needed for about, say, 99% of the time. Therefore, large amounts of radio resources will often be occupied to no avail here as well. It is thus a problem to increase efficiency by avoiding waste of radio resources in data communications between a network node and a wireless device, and at the same time achieve sufficient reliability in the data communications.